useReducer

Way back in Module 2, I shared my thoughts on global state management tools like Redux. One of the things I said is that React has “absorbed” some of the best parts of Redux.

In this lesson, we're going to talk about reducers, a feature plucked straight out of Redux, and implemented in React with the useReducer hook.

Now, Redux is known for having a pretty steep learning curve; there are a bunch of abstract concepts and vernacular that we need to become familiarized with. Unfortunately, the useReducer hook has imported all of that complexity as well. We're going to cover a lot of new ideas in this lesson!

A room full of confused faces (info)

I'm not sure how common this is around the world, but in North America, Computer Science programs at universities often have a “co-op” component, where students spend a few months doing an internship at a real-world company or organization. At Khan Academy, we hired about a dozen interns every summer.

To help them get started, we'd run training sessions during their first week on every major part of our stack. One developer would do one on Python, another on Google App Engine, etc.

My first year at Khan Academy, I volunteered to do the Redux training, and it was an unmitigated disaster 😅. It turns out, it's super hard to explain how Redux works! Pretty much from the beginning, those poor students were very, very confused.

The following year, I got another chance, and I totally changed how I covered it. Fortunately, it went a bit more smoothly that time. But it really made me appreciate how tricky Redux can be!

Intro to useReducer

Video Summary

In React, there are two ways to create state variables: the useState hook, like we've been using throughout this course, and the useReducer hook. Both hooks allow us to create and update state variables.

The big innovation with useReducer is that it teases apart two separate ideas:

The actions that fire in our application, like the user adding a new todo, or marking a todo as completed.
The state-updating logic that runs when an action occurs.

In this video, I demonstrate how useReducer works by migrating our Todo list application to use useReducer instead of useState. It's a difficult video to fully summarize, but essentially we:

Create a reducer function to hold all of the state-updating logic
Use the dispatch function to tell React when an action occurred
Update the 3 bits of business logic — creating a todo, toggling a todo, and deleting a todo — to use this new flow.

The drawback of useReducer is that there's more scaffolding required. We have to jump through a couple of hoops.

The benefit is that it forces us to group our state-updating logic together. There is no setTodos function; the only way to change the todos state is to dispatch an action.

Also, because the reducer function lives outside our component, we can easily set up unit tests without requiring us to mount any components.

Essentially, useReducer presents an alternative structure we can use for our state-updating logic. It may not be worth the boilerplate in simple cases, but it does nudge us towards a good structure, and this can really help in complex situations.

A relatively niche hook (info)

The useReducer hook, in my experience, isn't used super widely. In the codebase for this course platform, for example, I use the useReducer hook exactly 3 times. To put that in perspective, I use the useState hook >300 times.

I even debated not covering it in this course, since I don't want to waste your time with something you won't use every day. But I decided to include it for 2 reasons:

This module is called “happy practices”, and few things make me as happy as a well-structured reducer. It can be a fantastic tool for organizing components with complex state requirements. I don't use it often, but I find it really great when I do use it.
It's a core part of the React library, and you will stumble upon it every now and then. Some developers really enjoy useReducer and use it as their primary tool for state management. And so, to prevent any confusion when you encounter these resources, it's worth understanding it at a high level.

All of that said, it is 100% possible to build a production-ready app that never uses useReducer. If you're having trouble making sense of it, please don't stress about it. You can definitely skip this part of the course if you'd prefer. 😄

Here's the original playground, without useReducer:

Code Playground

import React from 'react';

import CreateNewTodo from './CreateNewTodo';

import TodoList from './TodoList';

function App() {

const [todos, setTodos] = React.useState([]);

function handleCreateTodo(value) {

setTodos([

...todos,

{

value,

id: crypto.randomUUID(),

]);

}

function handleToggleTodo(id) {

setTodos(

todos.map((todo) => {

if (todo.id !== id) {

return todo;

}

return {

...todo,

isCompleted: !todo.isCompleted,

};

})

);

}

function handleDeleteTodo(id) {

setTodos(todos.filter((todo) => todo.id !== id));

}

return (

<TodoList

todos={todos}

handleToggleTodo={handleToggleTodo}

handleDeleteTodo={handleDeleteTodo}

</div>

<CreateNewTodo

handleCreateTodo={handleCreateTodo}

</div>

);

}

export default App;

And here's the final code from the video above, with useReducer:

Code Playground

import React from 'react';

import CreateNewTodo from './CreateNewTodo';

import TodoList from './TodoList';

function reducer(todos, action) {

if (action.type === 'create-todo') {

return [

...todos,

{

value: action.value,

id: action.id,

];

} else if (action.type === 'toggle-todo') {

return todos.map((todo) => {

if (todo.id !== action.id) {

return todo;

}

return {

...todo,

isCompleted: !todo.isCompleted,

};

});

} else if (action.type === 'delete-todo') {

return todos.filter((todo) => todo.id !== action.id);

}

function App() {

const [todos, dispatch] = React.useReducer(reducer, []);

function handleCreateTodo(value) {

dispatch({

type: 'create-todo',

id: crypto.randomUUID(),

value,

});

}

function handleToggleTodo(id) {

dispatch({

type: 'toggle-todo',

id,

});

}

function handleDeleteTodo(id) {

dispatch({

type: 'delete-todo',

id,

});

}

return (

<TodoList

todos={todos}

handleToggleTodo={handleToggleTodo}

handleDeleteTodo={handleDeleteTodo}

</div>

Note: I made one small tweak to this code from the video. Before, the ID was generated inside the reducer, using crypto.randomUUID(). In this updated playground, we create that ID in the handleCreateTodo function, passing it in with the action. This was done to keep the reducer pure; more on this below.

Why is it called a “reducer”? (info)

The name “reducer” comes from the JavaScript array method, reduce. It allows us to combine an array of items into a single final value.

We don't cover the reduce array method in this course because I don't recommend using reduce. It used to be one of my favourite methods, until I realized that it was making my code unnecessarily difficult to understand. I have yet to find any situation in which reduce improves code readability, compared to a similar approach that uses something like forEach.

For example: the most common use case for reduce is to add up an array of numbers. Most tutorials use this example to introduce the reduce method, because it shows how useful it can be:

function sumNumbers(list) {
  return list.reduce((acc, item) => {
    return acc + item;
  }, 0);
}

That's pretty slick, but we can solve the same problem using a more-widely-understood .forEach loop:

function sumNumbers(list) {
  let sum = 0;
  list.forEach(item => {
    sum += item;
  });

  return sum;
}

But yeah, if you'd like to learn more about the reduce method, or understand where the name “reducer” came from, I recommend checking out this blog post from Dave Ceddia:

What is a Redux Reducer?

Reducers should be pure functions

One gotcha with reducers is that they must be pure functions.

A pure function is a function that always returns the same output given the same inputs. For example, this is a pure function:

function addNums(a, b) {
  return a + b;
}

When I run the code addNums(1, 1), it will return 2 every single time.

By contrast, here's an impure function:

function getRandomNumber() {
  return Math.random();
}

Every time I run the code getRandomNumber(), I get a different result, since it generates a random value every single time:

getRandomNumber(); // 0.0564345954320411
getRandomNumber(); // 0.8482841158362815

When it comes to the useReducer hook, our reducer functions must be pure. They must always return the same output, given the same input.

It's startlingly easy to make this mistake. In fact, I made this mistake myself, while filming the video for this lesson. 😅

In the video above, I wind up with a reducer that looks like this:

function reducer(todos, action) {
  if (action.type === 'create-todo') {
    return [
      ...todos,
      {
        value: action.value,
        id: crypto.randomUUID(),
      },
    ];
  }
  // ✂️ Other actions omitted for brevity
}

That crypto.randomUUID() expression produces a different value every time. As a result, we get a different output when calling the function with the same input:

reducer([], { value: 'buy groceries' });
// -> [{ value: 'buy-groceries', id: 'c455ebae-db9f-42f7-8ec5-c3a0e169938c' }]

reducer([], { value: 'buy groceries' });
// -> [{ value: 'buy-groceries', id: '5f3c38bb-1b32-430e-8282-d489b546ac1b' }]

Here's the solution: We can pass these impure values into the reducer, through the action.

For example:

function reducer(todos, action) {
  if (action.type === 'create-todo') {
    return [
      ...todos,
      {
        value: action.value,
        id: action.id,
      },
    ];
  }
  // ✂️ Other actions omitted for brevity
}


// We would then use it like this:
const action = {
  value: 'buy groceries',
  id: crypto.randomUUID(),
};

reducer([], action);

As I mentioned, it's an easy mistake to make, but fortunately, the solution tends to be pretty straightforward, most of the time.

You can learn more about the useReducer hook in the official documentation.

Do reducers actually need to be pure? (warning)

So, you might have noticed: despite the fact that I was breaking the rules in the above video, everything still seemed to work! It didn't seem to matter that my reducer was impure.

In practice, impure reducers actually do work in most situations, but there are some rare edge cases where strange things can happen if our reducers are impure.

What are those rare edge-cases? One example has to do with Suspense, which we'll discuss in the next module. In certain situations, React will re-run the reducer, with the original state + action. When that happens, our todo will be recreated with a different ID.

Now, suppose we were persisting the todo in a database, using the ID as its identifier. It could cause some weird bugs if React decides to randomly change the ID later on!

Honestly, things will probably be fine if your reducers aren't 100% pure, but here's the thing: the React team expects us to write pure reducers. They make a big deal about this in the official docs.

Just because an impure reducer works properly today doesn't mean it'll work properly with future versions of React. Personally, I don't want a ticking time bomb in my codebase!